The presented invention relates generally to the use of hardware description languages to specify circuit logic design in a format that is acceptable to logic synthesis tools, and, more particularly, to a method for translating non-Verilog HDL containing conditional expressions to Verilog HDL format and syntax.
The soundness of logic design of hardware such as complex central processor units (CPUs) must be tested prior to actually manufacturing the hardware. Logic design may be specified in the form of Boolean equations or a hardware description language (HDL) description in a language such as Verilog HDL, an IEEE standard hardware description language (IEEE Std 1364-1995). A routine can be written in an HDL such as Verilog HDL and then be converted into a logic gate circuit using a logical synthesis tool, such as Synopsys Design Compiler(trademark), operating on a general-purpose computer. In this manner, the logic design can be proven out.
Verilog HDL, as an accepted standard, is a language accepted as an input format by many design tools available on the market today. A concern arises, therefore, when a hardware description language other than Verilog HDL is used, generically referred to as a non-Verilog HDL, since third party design tools that will accept Verilog HDL may not readily accept another HDL. Since it is desirable to increase design productivity and to thus shorten the design cycle of CPUs and other relevant hardware, it is important to leverage existing and advanced tools even if they do not accept the non-Verilog HDL. This requires that the non-Verilog HDL be translated into Verilog HDL so that it can be readily used with available tools. An important aspect of the translation into Verilog HDL is that the translation be logically correct; additionally, certain inherent semantics of the code must be preserved. Logic synthesis tools such as the Synopsys Design Compiler(trademark) must be able to produce optimal results from the translated code.
A difficulty is encountered in the translation process when certain conditional expressions that are frequently used in the non-Verilog HDL are missing in Verilog HDL syntax and thus not recognized by the Verilog HDL. These conditional expressions may be broken into three types: IF expressions, CASE expressions, and COND expressions. An IF expression provides a choice between several expressions. The format of an IF expression is:
IF ifcond THEN exp1 ELSE exp2
A CASE expression returns the value of one expression out of N expressions, depending upon the value of a controlling expression. The format of a CASE expression is:
CASE caseexpr OF BEGIN
[c1] exp1;
[c2] exp2;
.
.
.
[cN] expN;
[ ] expN+1;
END;
A COND expression returns the value of one expression out of N expressions, depending on the value of the controlling expressions. The format of a COND expression is as follows:
COND BEGIN
[sel_exp1] exp1;
[sel_exp2] exp2;
.
.
.
[ ] expN+1;
END;
These types of expressions (IF/CASE/COND) will be generically referred to as xe2x80x9cICC expressionsxe2x80x9d hereafter.
The approaches to translating the various types of ICC expressions into Verilog HDL each have problems. First, a possible solution is the use of a nested conditional operator xe2x80x9c?:xe2x80x9d in the translated expression to implement the logic of the ICC expression that was translated. Consider the following examples. An IF expression of a:=IF b THEN c ELSE d; can be translated to a=b ? c: d; and a CASE expression of:
a:=CASE caseExp OF BEGIN
[xe2x80x200] b;
[xe2x80x201] c;
[xe2x80x210] d;
[xe2x80x211] e;
[ ] RETAIN;
END;
can be translated to
a=(caseExp==2xe2x80x2b00) ? b
:(caseExp==2xe2x80x2b01) ? c
:(caseExp==2xe2x80x2b10) ? d
:(caseExp==2xe2x80x2b11) ? e
a;
A COND expression is translated in a similar fashion to the CASE expression.
In the above translations of the IF and CASE expressions into Verilog, note the occurrence of the xe2x80x9c?:xe2x80x9d nested conditional operator. This approach to translating is simple and the generated Verilog HDL is clean and easy to read. Unfortunately, however, the performance of the generated Verilog code is very bad. What could be done with a single multiplexer in the pre-translated code is instead interpreted by logic synthesis tools as a multi-level chain of multiplexers in the translated code. This leads to very poor synthesis results as will be later described.
Second, ICC expressions of non-Verilog HDL code can be translated to Verilog xe2x80x9cIFxe2x80x9d, xe2x80x9cCASExe2x80x9d statements as shown below. Consider the same IF and COND expressions above. For the IF expression of a:=IF b THEN c ELSE d; the translation would be:
always @(b or c or d)
if(b)
a=c;
else
a=d;
The above CASE expression of:
a:=CASE caseExp OF BEGIN
[xe2x80x200] b;
[xe2x80x201] c;
[xe2x80x210] d;
[xe2x80x211] e;
[ ] RETAIN;
END;
can be translated to
always @(caseExp or b or c or d or e)
begin
case (caseExp)
2xe2x80x2b00: a=b;
2xe2x80x2b01: a=c;
2xe2x80x2b10: a=d;
2xe2x80x2b11: a=e;
default: a=a;
endcase
This second approach overcomes the shortcoming of the first approach since synthesis tools can recognize that a CASE statement can be interpreted as a single multiplexer rather than a multiple-level chain of multiplexers. A high quality implementation can thus be generated from the translated Verilog code using this approach.
This solution, however, has a severe limitation because it only works for non-nested ICC(IF/CASE/COND) expressions. But since ICC expressions may occur anywhere within another expression and thus be nested, this approach is limited in its usefulness. Consider, for instance, the following expression containing a nested IF expression that cannot be readily translated using this second approach:
a:=IF ( IF b THEN xe2x80x2010 ELSE xe2x80x2111)
THEN d
ELSE e;
Also, consider this additional example of an expression containing a nested ICC expression:
a:=(IF(b) THEN c ELSE d) XOR COND BEGIN
[sel_exp1] e;
[sel_exp2] f;
[sel_exp3] IF (g) THEN h ELSE i;
[ ] j;
END;
In both of these examples, there is no way to readily translate the code to Verilog IF/CASE statements and so the first approach, with its poor synthesis performance, must be used for code containing nested ICC expressions.
The properties associated with each of these two prior art approaches is best illustrated by example. Consider that the following is an example of a software module written in a non-Verilog HDL; note that the software module usually is written for the cell or block hardware level:
fub mux;
begin xe2x80x9cmuxxe2x80x9d
interface(
input node in1[3:0];
input node in2[3:0];
input node in3[3:0];
input node in4[3:0];
input node in5[3:0];
input node in6[3:0];
input node in7[3:01];
input node in8[3:0];
input node sel[2:01];
output node out[3:0];
);
structural main;
begin xe2x80x9cmuxd4v mainxe2x80x9d
out:=
case sel of
begin
[xe2x80x2000] in1;
[xe2x80x2001] in2;
[xe2x80x2010] in3;
[xe2x80x2011] in4;
[xe2x80x2100] in5;
[xe2x80x2101] in6;
[xe2x80x2110] in7;
[xe2x80x2111] in8;
end;
end xe2x80x9cmux mainxe2x80x9d;
end xe2x80x9cmuxxe2x80x9d;
If this software module is translated to Verilog HDL with the first approach using the xe2x80x9c?:xe2x80x9d Verilog conditional operator, the result would be as follows:
module mux(in1,in2,in3,in4,in5,in6,in7,in8,sel,out);
input [3:0] in1;
input [3:0] in2;
input [3:0] in3;
input [3:0] in4;
Input [3:0] in5;
input [3:0] in6;
input [3:0] in7;
input [3:0] in8;
input [3:0] sel;
output [3:0] out;
reg [3:0] out;
/* xe2x80x9cmuxd4v mainxe2x80x9d */
always @(sel or in5 or in6 or in7 or in8 or in1 or in2 or in3 or in4)
begin
out=(sel==3xe2x80x2b000) ? in1
:(sel==3xe2x80x2b001) ? in2
:(sel==3xe2x80x2b010) ? in3
:(sel==3xe2x80x2b011) ? in4
:(sel==3xe2x80x2b100) ? in5
:(sel==3xe2x80x2b101) ? in6
:(sel==3xe2x80x2b110) ? in7
:in8;
end
/* xe2x80x9cmuxd4v mainxe2x80x9d */
endmodule
As previously mentioned, the performance of the generated Verilog code using this first approach is not good because logic synthesis tools interpret the code as multi-level chain of multiplexers. The synthesis result generated from the code by a logic synthesis tool such as the Synopsys Design Compiler(trademark) after optimization is shown in FIG. 7. Since it can be seen that the critical path of FIG. 7 is still very long, a second optimization was preformed, the result of which is shown in FIG. 8. For purposes of illustration only, a timing and area analysis of FIGS. 7 and 8 revealed that the timing associated with FIG. 8 is approximately two times as fast as that associated with FIG. 7, but that the combinational area, or real estate, utilized by the optimization of FIG. 8 is almost five times greater than that of FIG. 7.
Now consider that the non-Verilog HDL module used in the above example is translated using the second approach of translating the non-Verilog HDL code to Verilog xe2x80x9cIfxe2x80x9d and xe2x80x9cCasexe2x80x9d statements; the following code is achieved:
module mux(in1,in2,in3,in4,in5,in6,in7,in8,sel,out);
input [3:0] in1;
input [3:0] in2;
input [3:0] in3;
input [3:0] in4;
input [3:0] in5;
input [3:0] in6;
input [3:0] in7;
input [3:0] in8;
input [2:0] sel;
output [3:0] out;
reg [3:0] out;
/* xe2x80x9cmuxd4v mainxe2x80x9d */
always @(sel or in5 or in6 or in7 or in8 or in1 or in2 or in3 or in4)
begin
case (sel) //synopsys Infer13 mux
3xe2x80x2b000: out=in1;
3xe2x80x2b001: out=in2;
3xe2x80x2b010: out=in3;
3xe2x80x2b011: out=in4;
3xe2x80x2b100: out=in5;
3xe2x80x2b101: out=in6;
3xe2x80x2b110: out=in7;
3xe2x80x2b111: out=in8;
endcase
end
/* xe2x80x9cmuxd4v mainxe2x80x9d */
endmodule
The synthesis result generated from this translated code by a logic synthesis tool such as the Synopsys Design Compiler(trademark) after optimization is shown in FIG. 9. A representative timing and area analysis of the optimization of FIG. 9 indicated that the timing associated with FIG. 9 is 3.6 times better than for FIG. 7. There is an improvement of 17% in area utilization over FIG. 7 and more than a 500% improvement in area utilization over the second optimization reflected in FIG. 8 for the same timing result.
From the above analysis, it is clear that there currently exists no translation approach in the art for readily translating non-Verilog HDL ICC expressions into Verilog HDL syntax in a manner that avoids the performance problems associated with the first, xe2x80x9c?:xe2x80x9d nested conditional operator translation approach and that can overcome the nested ICC expression limitation of the second translation approach. There is therefore an unmet need in the art to be able to readily and accurately translate all ICC conditional expressions occurring within non-Verilog HDL, including nested ICC expressions, to Verilog HDL in a manner that overcomes these problems and limitations while maintaining the Verilog HDL structure required for synthesis.
The present invention presents a method for translating conditional expressions of a non-Verilog hardware description language (HDL) program used to specify a logic design, that are not recognized by Verilog HDL. The methodology of the present invention may be implemented as executable computer program instructions of a computer readable medium that when executed by a processing system cause the processing system to translate non-Verilog conditional expressions to syntax recognized by Verilog HDL.
According to an embodiment of the invention, for each module of the non-Verilog containing one or more assign statements, which in turn have a plurality of IF/CASE/COND (ICC) expressions, a global link list that contains the plurality of IF/CASE/COND (ICC) expressions contained in the one or more assign statements is created; each ICC expression of the plurality of ICC expressions of the assign statement is characterized as having one or more variables. If an ICC expression of the plurality of ICC expressions contained within an assign statement of the assign statements is part of a conditional or binary operator expression, a globally incremental variable that is representative of a corresponding variable of the ICC expression is created. Next, the ICC expression is assigned to the globally incremental variable, thereby replacing the ICC expression with the globally incremental variable in the assign statement and in the global link list of the assign statement. Creating a globally incremental variable and replacing the ICC expression with the globally incremental variable is repeated for each variable within the ICC expression so as to generate one or more globally incremental variables in the assign statement and in the global link list that correspond to the one or more variables of the ICC expression. An always statement of the module, with an event expression having one or more members, that is representative of the assign statement and recognized by Verilog HDL is created by placing the one or more globally incremental variables contained within the global link list of the assign statement as the one or more members of the event expression. Synthesis can then be performed on the always statement by a processor to generate a logic circuit representative of the module of the non-Verilog HDL program. The above method can be performed for any or all modules of interest in the non-Verilog HDL program.
The above methodology can be expanded to address the concerns presented by other conditional expressions of concern in the non-Verilog HDL program, including simple ICC expressions, nested ICC expressions, special expressions and edge-triggered statements. If the ICC expression contained within the right hand side expression of an assign statement is determined to be a simple ICC expression, it is translated to an IF/CASE Verilog statement so that synthesis can be performed on it by a processor. For instance, for a simple IF expression, the left hand side expression of the assign statement is passed to the IF expression to create an IF Verilog statement. If the ICC expression is a simple CASE expression, the left hand side expression of the assign statement is passed to the CASE expression to create a CASE Verilog statement. If the ICC expression is a simple COND expression, the left hand side expression of the assign statement is passed to the COND expression and a special CASE Verilog statement is created from the COND expression. If the ICC expression is part of a conditional or binary operator expression, the methodology described above is employed. Moreover, if the ICC expression is nested within a principal ICC expression of the assign statement, the left hand side expression of the assign statement is passed to the ICC expression and then recursively passed to the principal ICC expression at a leaf level of the principal ICC expression of the assign statement. For a special ICC expression, the ICC expression is substituted with a Verilog-compatible expression that is assigned to the left hand side expression of the assign statement. Finally, if the assign statement in which the ICC expression is contained is an edge triggered assign statement, an edge triggered always statement in created into which the ICC expression is placed.